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(1) Real Party in Interest 

The examiner has no comment on the statement, or lack of statement, identifying by 
name the real party in interest in the brief. 

(2) Related Appeals and Interferences 

The examiner is not aware of any related appeals, interferences, or judicial proceedings 
which will directly affect or be directly affected by or have a bearing on the Board's decision in 
the pending appeal. 

(3) Status of Claims 

The following is a list of claims that are rejected and pending in the application: 
Claims 3-5, 7-10, 12-15 and 40 are rejected. 

(4) Status of Amendments After Final 

The examiner has no comment on the appellant's statement of the status of amendments 
after final rejection contained in the brief. 



(5) Summary of Claimed Subject Matter 

The examiner has no comment on the summary of claimed subject matter contained in 
the brief. 
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(6) Grounds of Rejection to be Reviewed on Appeal 

The examiner has no comment on the appellant's statement of the grounds of rejection to 
be reviewed on appeal. Every ground of rejection set forth in the Office action from which the 
appeal is taken (as modified by any advisory actions) is being maintained by the examiner except 
for the grounds of rejection (if any) listed under the subheading "WITHDRAWN 
REJECTIONS." New grounds of rejection (if any) are provided under the subheading "NEW 
GROUNDS OF REJECTION." 



(7) Claims Appendix 

The examiner has no comment on the copy of the appealed claims contained in the 
Appendix to the appellant's brief. 



(8) Evidence Relied Upon 

6,937,597 Rosenberg et al. 08-2005 

5,995,608 Detampel, Jr. et al. 1 1-1999 

6,421,339 Thomas 07-2002 

5,978,463 Jurkevics et al. 11-1999 

5,680,392 Semaan 10-1997 
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(9) Grounds of Rejection 

The following ground(s) of rejection are applicable to the appealed claims: 

Claim Rejections - 35 USC § 102 

1. The following is a quotation of the appropriate paragraphs of 35 U.S.C. 102 that form the 
basis for the rejections under this section made in this Office action: 

A person shall be entitled to a patent unless - 

(e) the invention was described in (1) an application for patent, published under section 122(b), by another filed 
in the United States before the invention by the applicant for patent or (2) a patent granted on an application for 
patent by another filed in the United States before the invention by the applicant for patent, except that an 
international application filed under the treaty defined in section 351(a) shall have the effects for purposes of this 
subsection of an application filed in the United States only if the international application designated the United 
States and was published under Article 21(2) of such treaty in the English language. 

2. Claim 40 is rejected under 35 U.S.C. 102(e) as being anticipated by Rosenberg et al. (US 
6,937,597; hereinafter Rosenberg). 

As to claim 40, Rosenberg shows a method of adding an additional endpoint to an 
already active audio conference (Figure 3-5; col. 15-16; note multiparty conferencing which 
allows an already existing conference to include additional conferees through the use of INVITE 
messages), the method comprising: 

selecting an endpoint not already participating in an audio conference (Figure 3-4; col. 5, 
line 33 to col. 6, lines 35; note user cz 1 10 wants to communicate with user henning 210 and 
further sends an INVITE request 300; further note that the method of Figure 4 is also applied to 
SIP operations including third or later parties in a conference or multicast call; in this instance, 
since no communication is established with user henning 210 yet, it can be seen the user henning 
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210 is not yet participating in an audio conference; see also col. 15-16 regarding multiparty 
conferencing); 

obtaining a destination address for the selected endpoint from a packet-switched 
conferencing system component (Figure 3-4; col. 6, lines 14-18; note location server 230 (i.e. 
packet- switched conferencing system) returns a location of hgs@play to proxy server 230 as the 
location of user henning 210), 

providing the destination address to a multipoint control unit managing the audio 
conference (Figure 3-4; col. 6, lines 14-18; note the location (i.e. hgs@play of user henning 210) 
is returned (i.e. provided) to proxy server 230); 

placing an outbound point to point call from the multipoint control unit to the 
additional endpoint (Figure 3-4; step 310; col. 6, lines 19-24; note that after receiving the 
location of user henning 210, proxy server 220 sends a new INVITE request to hgs@play. As in 
step 300, this INVITE request also contains FROM, TO, and CALL-ID header fields. It is 
particularly noted that the call identifier in the CALL- ID header field is the same, in order to 
maintain an association with the original request.); and 

adding the additional endpoint to the audio conference (Figure 3-4; note steps 320 
onward details the ACKs and replies from both the caller (i.e. user cz) and callee (i.e. henning) 
through proxy server 220, further establishing the call between both parties. It is further noted 
that the method in Figure 3 is also applied to third party not yet included in an established 
communication/conference. The third party is in general the callee to be invited to the 
conference. See also col. 15-16 regarding inviting additional conferees to multiparty 
conferencing.). 
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Claim Rejections - 35 USC § 103 

3. The following is a quotation of 35 U.S.C. 103(a) which forms the basis for all 
obviousness rejections set forth in this Office action: 

(a) A patent may not be obtained though the invention is not identically disclosed or described as set forth in 
section 102 of this title, if the differences between the subject matter sought to be patented and the prior art are 
such that the subject matter as a whole would have been obvious at the time the invention was made to a person 
having ordinary skill in the art to which said subject matter pertains. Patentability shall not be negatived by the 
manner in which the invention was made. 

4. This application currently names joint inventors. In considering patentability of the 
claims under 35 U.S.C. 103(a), the examiner presumes that the subject matter of the various 
claims was commonly owned at the time any inventions covered therein were made absent any 
evidence to the contrary. Applicant is advised of the obligation under 37 CFR 1.56 to point out 
the inventor and invention dates of each claim that was not commonly owned at the time a later 
invention was made in order for the examiner to consider the applicability of 35 U.S.C. 103(c) 
and potential 35 U.S.C. 102(e), (f) or (g) prior art under 35 U.S.C. 103(a). 

5. Claims 3, 7 and 12 rejected under 35 U.S.C. 103(a) as being unpatentable over 
Detampel, Jr. et al (US 5,995,608; hereinafter Detampel) in view of Rosenberg et al. (US 
6,937,597; hereinafter Rosenberg). 

As to claim 7, Detampel shows a method (Figure 1; abstract; method for setting up an 
on-demand conference call in a telecommunications system) for adding an additional endpoint to 
an audio conference in a purely packet-switched audio conferencing system, said method 
comprising: 

placing a call from an endpoint (figure 6, step 601, caller dials) to a packet- switched 
conferencing system component (Figure 3, CACS 301), 
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said call indicating an audio conference (Figure 6, step 601; col. 9, lines 61-62, caller 
dials a unique on-demand conference number); 

selecting, in a conference allocation and control system (Figure 1, CACS 103; Figure 3, 
CACS 301) in said audio conferencing system (figure 1, system 10), a multiple control unit 
(Figure 1; one of bridge servers lOla-lOln) to host said audio conference (col. 5, lines 36-38, 
when an on-demand conference call request comes in, the CACS determines which bridge 
servers 101 have sufficient availability of ports to handle the on-demand conference call; col. 9, 
lines 61-66; the steps take place as described above to select the bridge server 101 having enough 
ports available for the subscriber's maximum call). 

Also, Detampel shows in Figure 6 the details of the call flow diagram of the conferencing 
system. It is noted that step 621 is further detailed in Figure 7 and col. 11, lines 32-63. It is 
noted that conferees are allowed to enter DTMF commands which are conveyed to a servicing 
bridge server. The commands provide control over several in-conference options. The 
commands include at least access to outside lines for other purposes. However, Detampel does 
not specifically show what further actions the conferees are allowed to take while in conference. 

Detampel shows all of the elements including the multipoint control unit and packet- 
switched conferencing system component, as discussed above. However, Detampel does not 
specifically show initiating an outbound call request from said multipoint control unit to said 
packet- switched conferencing system component, wherein said call request indicates said 
additional endpoint which is not already participating in the audio conference; returning a 
destination address from said packet- switched conferencing system component to said selected 
multipoint control unit, said destination address corresponding to said additional endpoint; and 
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establishing a point-to-point outbound c all from said multipoint control unit to said additional 
endpoint based on said destination address, thereby bringing said additional endpoint into said 
audio conference. 

However, the above-mentioned claim limitations are well-established in the art as 
evidenced by Rosenberg. Rosenberg shows a method for creating, modifying, and terminating 
associations between Internet end systems, particularly, but not exclusively, in connection with 
Internet telephony communication, (see abstract). 

Specifically, Rosenberg shows initiating an outbound call request from said multipoint 
control unit to said packet-switched conferencing system component (Figure 3, step 310; col. 5, 
line 33 to col. 6, lines 35; note INVITE request received by proxy server 220 may send the target 
"henning" to a location server 230; further note that as stated in general terms, when the proxy 
server receives a request (such as an INVITE message) and then forwards the request towards 
the location of the callee. In a given example, the server responsible for the domain 
example.com may forward a call forjohn.doe@example.com to the server responsible for the 
address doe@sales.example.com. It is noted that SIP messages (i.e. INVITE) includes 
operations allowing a third or later parties in a conference or multicast call. See also col. 15-16 
regarding inviting additional conferees to multiparty conferencing.), 

wherein said call request indicates said additional endpoint which is not already 
participating in the audio conference (Figure 3-4, step 310; col. 5, line 33 to col. 6, lines 4; SIP 
messages (i.e. INVITE) includes operations allowing a third or later parties in a conference or 
multicast call. It is further noted that the method in Figure 3 is also applied to third party not yet 
included in an established communication/conference. The third party is in general the callee to 
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be invited to the conference. See also col. 15-16 regarding inviting additional conferees to 
multiparty conferencing.); 

returning a destination address from said packet-switched conferencing system 
component to said selected multipoint control unit (Figure 3-4; col. 5, line 33 to col. 6, lines 35; 
note location server 230 returns a location of hgs@play to proxy server 220 as the location of 
user henning), said destination address corresponding to said additional endpoint (Figure 3-4; 
col. 5, line 33 to col. 6, lines 35; note hgs@play is the location of user henning.); and 

establishing a point-to-point outbound c all from said multipoint control unit to said 
additional endpoint based on said destination address (Figure 3-4; note steps 320 onward details 
the ACKs and replies from both the caller (i.e. user cz) and callee (i.e. henning) through proxy 
server 220, further establishing the call between both parties. It is further noted that the method 
in Figure 3 is also applied to third party not yet included in an established 
communication/conference. The third party is in general the callee to be invited to the 
conference. See also col. 15-16 regarding inviting additional conferees to multiparty 
conferencing.); thereby bringing said additional endpoint into said audio conference (3-4; col. 5, 
line 33 to col. 6, lines 35; It is further noted that the method in Figure 3 is also applied to third 
party not yet included in an established communication/conference. The third party is in general 
the callee to be invited to the conference. Once the method performs 320 onwards, the invitation 
to the callee is processed and the callee is included in the conference. See also col. 15-16 
regarding inviting additional conferees to multiparty conferencing.). 

In view of the above, having the system of Detampel, then given the well-established 
teaching of Rosenberg, it would have been obvious to one of ordinary skill in the art at the time 
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of the invention to modify the system of Detampel as taught by Rosenberg, in order to provide 
relatively advanced telephony services, beyond call construction and destruction, such as call 
forwarding and transfer, call holding, camp-on queuing, and also three or more party 
conferencing (col. 1, lines 14-17) 

As to claim 3, modified Detampel shows that the step of placing a call, links said 
endpoint (Detampel: figure 1, user in network 106, 102; Figure 4, user 401-n) to said packet- 
switched conferencing system component (Detampel: Figures 1, 4, CACS 103) through said 
packet- switched audio conferencing system (Detampel: Figures 1, 4, 6; col. 8, lines 14-55). 

As to claim 12, Detampel further shows the step of dynamically routing an operator 
voice path to service (Examiner interprets this claim limitation as being the same as having an 
operator being able to service/handle components/servers in a packet switched network; col. 6, 
lines 58-62, shows the Operator Interface module 305 is the application program interface to the 
operator/maintenance stations 107, and handles operator request queue management, registration 
for operator- monitored bridge events, and operator updates to the subscriber database 104; 
Figure 6, col. 10, lines 14-67; shows the operator functions when an invalid passcode/PIN was 
supplied, however, for example purposes, the operator station is shown to interact with bridge 
101.; col. 4, lines 65-67; shows operator/maintenance stations 107 is connected to CACS through 
network 109 to provide operator interaction with system 10, that further includes multiple bridge 
servers lOla-n) multiple control units (Figure 1, bridge servers lOla-n). 
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6. Claims 4-5 are rejected under 35 U.S.C. 103(a) as being unpatentable over Detampel, Jr. 
et al (US 5,995,608; hereinafter Detampel) in view of Rosenberg et al. (US 6,937,597; 
hereinafter Rosenberg) in view of Thomas (US 6,421,339 Bl; hereinafter Thomas). 

As to claim 4, modified Detampel shows all of the elements except a location found 
signal indicating the selected multiple control unit. 

However, the above-mentioned claim limitation is well-established in the art as 
evidenced by Thomas. Specifically, Thomas shows a location found signal indicating the 
selected multiple control unit (Figure 3, col. 5, lines 25-30; gatekeeper GK 14 may screen or 
otherwise filter the data received in the LCF message from GK 44 and then send a LCF to the 
requester or calling endpoint. As will be obvious to network designers, the data returned to the 
calling party may be limited so that calls must be routed through the home gatekeeper rather than 
giving the calling endpoint enough data to place a call directly to a roaming user). 

In view of the above, having the system of Detampel and then given the well-established 
teaching of Thomas, it would have been obvious to one of ordinary skill in the art at the time of 
the invention to modify the method of Detampel as taught by Thomas, in order to allow the 
gatekeeper to monitor the contents of all call received by given users (col. 5, lines 32-33). 

As to claim 5, Detampel shows all of the elements except a location request signal. 

However, the above-mentioned claim limitation is well-established in the art as 
evidenced by Thomas. Specifically, Thomas shows a location request signal (Figure 3, LRQ). 

In view of the above, having the system of Detampel and then given the well-established 
teaching of Thomas, it would have been obvious to one of ordinary skill in the art at the time of 
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the invention to modify the method of Detampel as taught by Thomas, in order to allow the 
gatekeeper to monitor the contents of all call received by given users (col. 5, lines 32-33). 

7. Claims 8-10 are rejected under 35 U.S.C. 103(a) as being unpatentable over Detampel, 
Jr. et al (US 5,995,608; hereinafter Detampel) in view of Rosenberg et al. (US 6,937,597; 
hereinafter Rosenberg) in view of Jurkevics et al. (US 5,978,463; hereinafter Jurkevics). 

As to claim 8, modified Detampel shows all of the elements except supporting full 
service audio conferencing using a reservation system and a call agent. 

However, the above-mentioned claim limitation is well-established in the art as 
evidenced by Jurkevics. Specifically, Jurkevics shows full service audio conferencing (Figures 
2-4; abstract, audio conferencing system) using a reservation system (Figure 4, Autoscheduler 
28) and a call agent (Figure 1, client 10, Figure 4, Client program 20 running on Client 10). 

In view of the above, having the system of modified Detampel and then given the well- 
established teaching of Jurkevics, it would have been obvious to one of ordinary skill in the art at 
the time of the invention to modify the method of modified Detampel as taught by Jurkevics, in 
order to provide a substantially less labor intensive approach in audio conference scheduling 
(col. 3, lines 16-20). 

As to claim 9, modified Detampel shows that the reservation system and the call agent 
are tightly integrated (Jurkevics: Figure 4-5, shows the integration of the automatic scheduling 
system with the client program in scheduling a conference; col. 5, lines 33-48; shows different 
levels of service, unattended service (no agent attending the audio conference), standard level, 
and premiere level). 
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As to claim 10, modified Detampel shows that the reservation system and the call agent 
are loosely integrated (Jurkevics: Figure 4-5, shows the integration of the automatic scheduling 
system with the client program in scheduling a conference; col. 5, lines 33-48; shows different 
levels of service, unattended service (no agent attending the audio conference), standard level, 
and premiere level). 

8. Claims 13-14 are rejected under 35 U.S.C. 103(a) as being unpatentable over Detampel, 
Jr. et al (US 5,995,608; hereinafter Detampel) in view of Rosenberg et al. (US 6,937,597; 
hereinafter Rosenberg) in view of Semaan (US 5,680,392; hereinafter Semaan). 

As to claim 13, modified Detampel shows all of the elements except the step of 
renegotiating the destination of a voice path to move an audio conference participant from said 
selected multiple control unit to a second multiple control unit. 

However, the above-mentioned claim limitation is well-established in the art as 
evidenced by Semaan. Specifically, Semaan shows the step of renegotiating the destination of a 
voice path to move an audio conference participant from said selected multiple control unit to a 
second multiple control unit (Figure 2, 5; col. 11, lines 18-25; shows that if a user should wish to 
establish a conference with conferees who would be handled by the reservation controller of 
another domain, the bridge controller would pass the reservation request information onto the 
reservation request channel of the other reservation domain so that the appropriate reservation 
controller in the other domain could address the request; Figure 2 and 5, shows that each 
reservation controller is related to an MCU). 
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In view of the above, having the system of modified Detampel and then given the well- 
established teaching of Semaan, it would have been obvious to one of ordinary skill in the art at 
the time of the invention to modify the method of modified Detampel as taught by Semaan, in 
order to provide the possibility of allowing different MCUs and reservation controllers (of 
different companies), to interact with each other and share information regarding requests for 
reservations (col. 5, lines 29-37). 

As to claim 14, modified Detampel shows all of the elements except the step of moving 
said audio conference from said selected multiple control unit to a second multiple control unit. 

However, the above-mentioned claim limitation is well-established in the art as 
evidenced by Semaan. Specifically, Semaan shows the step of moving said audio conference 
(Figure 2, 5; col. 11, lines 18-25; shows that if a user should wish to establish a conference with 
conferees who would be handled by the reservation controller of another domain, the bridge 
controller would pass the reservation request information onto the reservation request channel of 
the other reservation domain so that the appropriate reservation controller in the other domain 
could address the request; Figure 2 and 5, shows that each reservation controller is related to an 
MCU) from said selected multiple control unit to a second multiple control unit (Examiner notes 
that there is a change in reservation controllers, there is also a change in MCUs). 

In view of the above, having the system of modified Detampel and then given the well- 
established teaching of Semaan, it would have been obvious to one of ordinary skill in the art at 
the time of the invention to modify the method of modified Detampel as taught by Semaan, in 
order to provide the possibility of allowing different MCUs and reservation controllers (of 
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different companies), to interact with each other and share information regarding requests for 
reservations (col. 5, lines 29-37). 

9. Claim 15 rejected under 35 U.S.C. 103(a) as being unpatentable over Detampel, Jr. et al 
(US 5,995,608; hereinafter Detampel) in view of Rosenberg et al. (US 6,937,597) in view of 
Semaan (US 5,680,392; hereinafter Semaan). 

As to claim 15, modified Detampel shows selected multiple control unit (Detampel: 
Figure 1, bridge server lOla-n) and the streaming protocol server (Rosenberg: col. 19; a 
conference participant can invite a SIP-speaking RTSP server into an existing conference, so as 
to appear as just another conference participant. Alternatively, for multicast conferences, an 
RTSP server can simply be given the same session description as was used for invitations). 

However, Detampel does not explicitly show the steps of providing said audio 
conference to a server from said selected multiple control unit; connecting a passive participant 
to said streaming protocol server; and broadcasting said audio conference from said streaming 
protocol server to a said passive participant. 

However, the above-mentioned claim limitation is well-established in the art as 
evidenced by Semaan. Specifically, Semaan shows the steps of providing said audio conference 
to a reservation controller from said selected multiple control unit (Figure 2, 5; col. 11, lines 18- 
25; shows that if a user should wish to establish a conference with conferees who would be 
handled by the reservation controller of another domain, the bridge controller would pass the 
reservation request information onto the reservation request channel of the other reservation 
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domain so that the appropriate reservation controller in the other domain could address the 
request; Figure 2 and 5, shows that each reservation controller is related to an MCU); 

connecting a passive participant to said reservation controller (col. 11, lines 18-25; col. 5, 
lines 20-29; if users 1 12c, 1 12e, 1 12f, 1 12g, 1 12h, and 1 12j should wish to participate in a 
multimedia conference, the services of the four different MCUs 126a-126d will be required. 
Thus, the two reservation controllers 130a, 130b must be contacted to reserve appropriate access 
and processing of the MCUs.); and 

broadcasting said audio conference from said reservation controller to a said passive 
participant (col. 8, line 65 to col. 9, line 9; shows that the conference mode includes broadcast 
monologue and broadcast dialogue). 

In view of the above, having the system of modified Detampel and then given the well- 
established teaching of Semaan, it would have been obvious to one of ordinary skill in the art at 
the time of the invention to modify the method of modified Detampel as taught by Semaan, in 
order to provide the possibility of allowing different MCUs and reservation controllers (of 
different companies), to interact with each other and share information regarding requests for 
reservations (col. 5, lines 29-37). 
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(10) Response to Arguments 

• Section A - Claim 40 stands rejected under 35 U.S.C. 102(e) as being anticipated by 
Rosenberg et al. (US Pat. 6,937,597: hereinafter Rosenberg) 

Regarding claim 40, Applicant has submitted that "Rosenberg's proxy server is 
fundamentally different from an MCU and does not perform the functions of either "managing 
an audio conference" or "placing an outbound call" as expressly recited functions of an MCU in 
claim 40" (see page 10, last *J[ to page 11, 1 st f of Brief). In support, the Applicant has submitted 
the following arguments: 

i. ". . .Rosenberg's proxy server simply cannot be equated with a multipoint control 

unit. . .Rosenberg's proxy server does not perform functions equivalent to the claimed 
multipoint control unit" (see page 10, last ^ of Brief); 

ii. "...claim 40 clearly recites "an already active audio conference" and "adding an 
additional endpoint to the audio conference"... Clearly, an already active audio 
conference has at least two participants and adding an additional participant certainly 
makes at least three" (see page 11, 2nd <][ of Brief); 

iii. ". . .the management or preparation of calls is wholly different from managing an 
audio conference between three or more participants. . ." (see page 1 1, 3 rd % of Brief); 

iv. "...it is illogical for the Examiner to rely heavily on Figures 3-4 and its corresponding 
description because this portion of Rosenberg is in no way directed to an audio 
conference. . ." (see page 11, last If to page 12, 1 st f of Brief); 
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v. ". . .Examiner makes clear that his rejection cannot be sustained because the "new" 
invite request simply does not denote another call..." (see page 12, 2nd 1 of Brief); 
and 

vi. ". . .Rosenberg does not disclose anything arranged as in independent claim 40 nor 
does Rosenberg disclose the identical invention in complete detail as required by law 
and USPTO examining guidelines" (see page 13, last 1 of Brief). 

However, the Examiner respectfully disagrees with the Applicant and assert that 
Rosenberg shows the claim limitations as presented in independent claim 40. 

In response to argument (i), the Examiner has abided by MPEP 21 12.02 - Process 
claims in the anticipation-based rejection of claim 40. MPEP 21 12.02 states: 

[MPEP 2112.02 - Process Claims] 

Under the principles of inherency, if a prior art device, in its normal and usual 
operation, would necessarily perform the method claimed, then the method claimed will 
be considered to be anticipated by the prior art device. When the prior art device is the 
same as a device described in the specification for carrying out the claimed method, it can 
be assumed the device will inherently perform the claimed process. 

The functions being relied upon in the argument pertains to the functions performed by 
the multipoint control unit (MCU). The functions include: (a) "managing the audio conference" 
and (b) "placing and outbound point to point call." 

In the rejections, the Examiner has relied upon the proxy server of Rosenberg to show the 
multipoint control unit since the proxy server of Rosenberg performs the functions of (a) 
"managing the audio conference" and (b) "placing and outbound point to point call." 

With respect to function (a) "managing the audio conference", it is noted that the call 
setup according to Session Initiation Protocol (SIP) is performed in relation to the proxy server. 



Application/Control Number: 10/697,810 
Art Unit: 2474 



Page 19 



The Examiner disagrees that Rosenberg's proxy server is confined only to reception and 
forwarding of SIP-related requests (i.e. INVITE requests) as stated in page 9, 1 st 1 of the Brief. 
Call setup between clients/callers are established using the proxy server using at least some SIP 
messages. Particularly, we look into INVITE requests/messages sent between proxy server and 
the clients/callers (Figure 3; col. 15, lines 37-49). A description of the use of at least INVITE 
messages/requests is described below for convenience: 

[Rosenberg: col. 3, lines 45-58] 

In general, each call is identified by a globally unique call identifier, carried in a 
CALL- ID header field of the SIP message. The call identifier is created by the originator 
and is used commonly by all call participants. The call identifier may be, for example, an 
alphanumeric or numeric string corresponding to the day and/or time of a call, which is 
associated with some identifier specific to the call originator. 

As mentioned above, SIP defines several methods. These may include the 
following. 

INVITE invites a user to a conference, BYE terminates a connection between 
two users in a conference, and OPTIONS solicits information about a user's capabilities, 
but does not set up a call. Accordingly, these methods are used to manage or prepare 
for calls . 



Thus, it is explicitly shown in the citation shown above that the use of INVITE 
messages/request are used to establish calls between callers and, in part, manages or prepares 
calls. Since the proxy server of Rosenberg allows for such use of messages (i.e. INVITE 
messages), and in turn, the proxy server of Rosenberg manages calls. 

However, it is further noted that the use of SIP is not limited to calls but also hosting 
conferences. Rosenberg further shows: 

[Rosenberg: col. 5, lines 33-40] 

The most important operation in SIP is that of inviting new participants to a call, 
whether a second party in a two-party call, or third or later parties in a conference or 



Application/Control Number: 10/697,810 
Art Unit: 2474 



Page 20 



multicast call . All other operations in SIP are essentially built on the operation of inviting 
additional callers . 

As shown above, the proxy server is not limited to managing calls but also managing 
conference calls. At least for the reasons shown above, the proxy server of Rosenberg shows the 
function (a) managing the audio conference as performed by the multipoint control unit. 

With respect to function (b), the Examiner has used the citations shown in Figure 4, step 
310 and col. 6, lines 19-24 showing ". . .proxy server sends a new INVITE request to 
hgs@play... this INVITE request also contains FROM, TO, and CALL-ID header fields. It is 
particularly noted that the call identifier in the CALL- ID header field is the same, in order to 
maintain an association with the original request. . . " In addition, Rosenberg details the 
properties of SIP calls in col. 3, lines 10-58. Certain sections are shown below for convenience: 

[Rosenberg: col. 3, lines 10-58] 

". . . In general, each call is identified by a globally unique call identifier, carried in a 
CALL- ID header field of the SIP message. The call identifier is created by the originator 
and is used commonly by all call participants. The call identifier may be, for example, an 
alphanumeric or numeric string corresponding to the day and/or time of a call, which is 
associated with some identifier specific to the call originator. . . ." 

". . .INVITE invites a user to a conference, BYE terminates a connection between 
two users in a conference, and OPTIONS solicits information about a user's capabilities, 
but does not set up a call. Accordingly, these methods are used to manage or prepare for 
calls..." 

Using the above-citations, since the new INVITE request includes the CALL- ID header 
fields, sending an INVITE request (i.e. new INVITE request from proxy server) is seen as being 
the same as "placing an outbound call..." since the INVITE message/request, invites a user to a 
conference and includes a CALL- ID header fields which identifies a call. In addition to the 



above, the Examiner would like to emphasize the use of a new INVITE request as issued by 
proxy server. Having a "new" INVITE request denotes another or a new call being placed by 
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proxy server. At least for the reasons shown above, the proxy server of Rosenberg shows the 
function (b) placing and outbound point to point call as performed by the multipoint control unit. 

Since the proxy server of Rosenberg performs the functions equivalent to the claimed 
multipoint control unit, the proxy server of Rosenberg can be equated with a multipoint control 
unit as set forth in MPEP 21 12.02. 

In response to argument (ii) that the reference fail to show certain features of 
applicant's invention, it is noted that the features upon which applicant relies (i.e., an already 
active audio conference has at least two participants and adding an additional participant 
certainly makes at least three) are not recited in the rejected claim(s). Although the claims are 
interpreted in light of the specification, limitations from the specification are not read into the 
claims. See In re Van Geuns, 988 F.2d 1181, 26 USPQ2d 1057 (Fed. Cir. 1993) and MPEP 2106 
- Patent Subject Matter Eligibility. 

Examiner agrees with the Applicant that "claim 40 clearly recites 'an already active audio 
conference' and 'adding an additional endpoint to the audio conference'." However, the 
Examiner points out that nowhere in claim 40 does it show any structure or additional limitations 
that further support that "an already active audio conference has at least two participants and 
adding an additional endpoint makes it three" One of ordinary skill in the art may establish an 
audio conference and wait for conferees to join. Thus, at least an audio conference does not 
require "at least two participants" as the Applicant submits. 

Unless explicitly claimed, the features which applicant relies upon need not be read into 
the claims. Thus at least for the given example shown above, the Examiner has applied the 
broadest reasonable interpretation and has abided by the guidelines set forth in MPEP 2106. 
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In response to argument (iii), Applicant's arguments fail to comply with 37 
CFR 1.111(b) because they amount to a general allegation that the claims define a patentable 
invention without specifically pointing out how the language of the claims patentably 
distinguishes them from the references. 

Applicant has submitted the general allegations that "the management or preparation of 
calls is wholly different from managing an audio conference between three or more participants" 
and "a MCU performs functions above and beyond managing or preparing calls when 
performing the claimed function of managing an audio call" (see page 1 1, 3 rd 1 of Brief). 
Currently, Examiner only has to show the MCU performing the functions (a) managing the audio 
conference" and (b) "placing an outbound call" as previously discussed. 

Until specific language is included in the claim to show how a MCU performs functions 
above and beyond managing or preparing calls" or how "the management or preparation of calls 
is wholly different from managing an audio conference between three or more participants", the 
Examiner will apply the broadest reasonable interpretation to the claimed subject matter as set 
forth in MPEP 2106 and 21 12.02. 

In response to argument (iv) that "...it is illogical for the Examiner to rely heavily on 
Figures 3-4 and its corresponding description because this portion of Rosenberg is in no way 
directed to an audio conference. . .", Applicant is reminded that MPEP 2141.02 IV - Differences 
Between Prior Art and Claimed Invention states: 

[MPEP 2141.02] 

A prior art reference must be considered in its entirety, i.e., as a whole , including 
portions that would lead away from the claimed invention. 
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In the rejections of the Final Office Action as shown above, the Examiner has relied upon 
Figure 3-4 and col. 15-16 of Rosenberg. Examiner has also clarified in the Advisory Action 
(09/28/2010) that "the Examiner relied heavily on Figures 3-4 and its corresponding description 
in col. 6." However, in argument (iv) as currently presented, the Applicant only r elied upon 
Figures 3-4 and col. 6 of Rosenberg and further argues that this portion of Rosenberg is not way 
directed to an audio conference. 

However, the Examiner respectfully disagrees. Figures 3-4 and its pertinent description 
in col. 6, lays the ground on how the overall system of Rosenberg utilizes SIP protocol in 
managing and preparing calls, as well as conferences. Again, the Examiner cites the following: 

[Rosenberg: col. 5, lines 33-40] 

The most important operation in SIP is that of inviting new participants to a call, 
whether a second party in a two-party call, or third or later parties in a conference or 
multicast call . All other operations in SIP are essentially built on the operation of inviting 
additional callers . 

Indeed Figures 3-4 and its pertinent description in col. 6 is directed to establishment and 
management of calls between different users/callers. However, the use of SIP and its 
corresponding protocol messages (i.e. INVITE, etc.) is not confined to calls but also 
establishment and management of calls making up a conference as evident in the above- 
mentioned citation. In addition, col. 15 to col. 16 shows the section of Multiparty Conference. 
The Applicant has shown certain parts of col. 15 to 16 that does not justify the complete 
functions of the Multipart Conference portion of Rosenberg (see Applicant's citation of 
Rosenberg in page 9 of Brief). Certain part of this section is shown below for convenience: 

[Rosenberg: col. 15, lines 37-49] 

By way of example, if A, who is part of a bridged conference at M, would like to 
call B outside of the bridge, and then invite B into the bridged conference. To do this, 
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A invites B. After A and B connect and talk, A invites B again (using the same call 
identifier) with ALSO set to M. It should be noted that A's SIP application does not know 
(and does not need to know) that M is actually performing a bridge function. In response 
to the ALSO set to M, B sends an INVITE to M, including a REQUESTED BY A. This 
lets M know that A invited B to join the bridge, so that it is possible that A is still 
connected to B directly (not through the bridge). To change this, M invites B, including 
REPLACES A, which causes B to drop A. 

As shown in the above-citations of col. 15, the system of Rosenberg is not confined to 
SIP calls but also to SIP conferences. The SIP calls actually make up the SIP conference. In the 
establishment of the bridged conferences, calls are performed by using INVITE messages per 
SIP protocol. The SIP calls shown above also follows the example given in Figure 4. 

At least for the reasons set forth above, it is not illogical for the Examiner to rely heavily 
on Figures 3-4 and its corresponding description because this portion of Rosenberg is in no way 
directed to an audio conference since, as discussed above, this lays the ground on how the overall 
system of Rosenberg utilizes SIP protocol in managing and preparing calls, as well as 
conferences. However, this misunderstanding could have been easily avoided if Applicant has 
abided by MPEP 2141.02 stating "A prior art reference must be considered in its entirety, i.e., as 
a whole , including portions that would lead away from the claimed invention." 

In response to argument (v) that ". . .Examiner makes clear that his rejection cannot be 
sustained because the "new" invite request simply does not denote another call...", the Examiner 
has used the citations shown in Figure 4, step 310 and col. 6, lines 19-24 showing ". . .proxy 
server sends a new INVITE request to hgs@play... this INVITE request also contains FROM, 
TO, and CALL- ID header fields. It is particularly noted that the call identifier in the CALL- ID 
header field is the same, in order to maintain an association with the original request. . . " In 
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addition, Rosenberg details the properties of SIP calls in col. 3, lines 10-58. Certain sections are 
shown below for convenience: 

[Rosenberg: col. 3, lines 10-58] 

". . .In general, each call is identified by a globally unique call identifier, carried in a 
CALL- ID header field of the SIP message. The call identifier is created by the originator 
and is used commonly by all call participants. The call identifier may be, for example, an 
alphanumeric or numeric string corresponding to the day and/or time of a call, which is 
associated with some identifier specific to the call originator. . . ." 

". . .INVITE invites a user to a conference, BYE terminates a connection between 
two users in a conference, and OPTIONS solicits information about a user's capabilities, 
but does not set up a call. Accordingly, these methods are used to manage or prepare for 
calls..." 

Using the above-citations, since the new INVITE request includes the CALL- ID header 
fields, sending an INVITE request (i.e. new INVITE request from proxy server) is seen as being 
the same as "placing an outbound call..." since the INVITE message/request, invites a user to a 
conference and includes a CALL- ID header fields which identifies a call. In addition to the 
above, the Examiner would like to emphasize the use of a new INVITE request as issued by 
proxy server. Having a "new" INVITE request denotes another or a new call being placed by 
proxy server and thus, the rejection is sustained based on the reasons set forth. 

In response to argument (vi) that ". ..Rosenberg does not disclose anything arranged as 
in independent claim 40 nor does Rosenberg disclose the identical invention in complete detail as 
required by law and USPTO examining guidelines, as already discussed above, the Examiner has 
relied upon the USPTO examining guidelines as presented in MPEP in the examination of the 
claims. Thus, the application the "proxy server" of Rosenberg to anticipate the multipoint 
control unit of claim 40 is valid as set forth in the rejections as well as the reasoning provided 
above. 
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Thus, given the current rejections and having the additional reasoning presented above 
with respect to arguments (i) to (vi), the Examiner has relied upon the USPTO examining 
guidelines as presented in MPEP and in this instance, Rosenberg anticipates the claimed 
invention as presented in claim 40. 

• Section B - Claims 3, 7 and 12 stand rejected under 35 U.S.C. 103(a) as being unpatentable 
over Detample, Jr. et al. (US Pat. 5,995,608: hereinafter Detample) in view of Rosenberg. 
Regarding claim 7, Applicant submits that "the Examiner has made a clear error in 
rejecting claims 3, 7, and 12 under 35 USC 103(a)" as being unpatentable over Detample in view 
of Rosenberg (see page 14 of Brief). In support, the Applicant has submitted the following 
arguments: 

i. ". . .Rosenberg in no way discloses initiating an outbound call request from a 
multipoint control unit which is also managing the audio conference. . .Rosenberg's 
proxy server cannot be equated with a multipoint control unit..." (page 15, 1st f); 

ii. "...Because bridge (M) learns B's address from B directly, the example does not meet 
the requirement that the address is obtained "from a packet- switched conferencing 
system component" (see page 16, 3rd H) and 

iii. ". . .any combination of the example multiple party bridge operation with the normal 
call procedure involving address lookup (e.g. Rosenberg's location server" is 
improper because such combination would destroy the operation of each case." (page 
16, 3rd©. 



Application/Control Number: 10/697,810 
Art Unit: 2474 



Page 27 



However, the Examiner respectfully disagrees with the Applicant and asserts that 
Detample in view of Rosenberg shows the claim limitations as presented in claim 7. 

In response to argument (i), Applicant has submitted arguments already presented in 
the arguments relating to claim 40. Thus, the Examiner applies the same reasoning presented in 
relation to claim 40. 

In response to argument (ii), instead of relying on the "bridge (M) learns B's address 
from B directly" to meet the claim requirements of claim 7, the Examiner has applied the 
following rejection: 

[Part of rejection of claim 7] 

returning a destination address from said packet-switched conferencing system 
component to said selected multipoint control unit (Figure 3-4; col. 5, line 33 to col. 6, 
lines 35; note location server 230 returns a location of hgs@play to proxy server 220 as 
the location of user hennin g), said destination address corresponding to said additional 
endpoint (Figure 3-4; col. 5, line 33 to col. 6, lines 35; note hgs@play is the location of 
user henning. ) 

Thus, at least for the rejection set forth, the Examiner has met the claim requirements of 
claim 7 as shown above. 

In response to argument (Hi) that there is no teaching, suggestion, or motivation to 
combine the references, the examiner recognizes that obviousness may be established by 
combining or modifying the teachings of the prior art to produce the claimed invention where 
there is some teaching, suggestion, or motivation to do so found either in the references 
themselves or in the knowledge generally available to one of ordinary skill in the art. See In re 
Fine, 837 F.2d 1071, 5 USPQ2d 1596 (Fed. Cir. 1988), In re Jones, 958 F.2d 347, 21 USPQ2d 
1941 (Fed. Cir. 1992), and KSR International Co. v. Teleflex, Inc., 550 U.S. 398, 82 USPQ2d 
1385 (2007). 
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In this case, the call procedure as well as the conference procedure laid in the section of 
Multiparty Conferencing in col. 15 both utilize the same protocols in the establishment and 
management of the communication. The system of Rosenberg is not confined to SIP calls but 
also to SIP conferences. The SIP calls actually make up the SIP conference. In the 
establishment of the bridged conferences, calls are performed by using INVITE messages per 
SIP protocol. The SIP calls shown above also follows the example given in Figure 4. 

Thus, given the current rejections and having the additional reasoning presented above 
with respect to arguments (i) to (iii), the Examiner has relied upon the USPTO examining 
guidelines as presented in MPEP and in this instance, Rosenberg anticipates the claimed 
invention as presented in claim 7. 

Regarding claims 3 and 12, the Applicant has relied upon the same arguments presented 
in claim 7. Thus, the Examiner applies the same reasoning presented in claim 7. 

• Section C - Claims 4-5 stand rejected under 35 U.S.C. 103(a) as being unpatentable over 
Detample, Jr. et al. (US Pat. 5,995,608; hereinafter Detample) in view of Rosenberg and 
Thomas (US Pat. 6,421,339; hereinafter Thomas). 

Regarding claims 4-5, the Applicant has relied upon the same arguments presented in 

claim 7. Thus, the Examiner applies the same reasoning presented in claim 7. 



• Section D - Claims 8-10 stand rejected under 35 U.S.C. 103(a) as being unpatentable over 



Detample, Jr. et al. (US Pat. 5,995,608; hereinafter Detample) in view of Rosenberg and 



Jurkevics et al. (US Pat. 5,978,463; hereinafter Jurkevics). 



Application/Control Number: 10/697,810 Page 29 

Art Unit: 2474 

Regarding claims 8-10, the Applicant has relied upon the same arguments presented in 
claim 7. Thus, the Examiner applies the same reasoning presented in claim 7. 

• Section E - Claims 13-15 stand rejected under 35 U.S.C. 103(a) as being unpatentable over 
Detample, Jr. et al. (US Pat. 5,995,608: hereinafter Detample) in view of Rosenberg. 

Regarding claims 13-15, the Applicant has relied upon the same arguments presented in 
claim 7. Thus, the Examiner applies the same reasoning presented in claim 7. 

(11) Related Proceeding(s) Appendix 

No decision rendered by a court or the Board is identified by the examiner in the Related 
Appeals and Interferences section of this examiner's answer. 
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For the above reasons, it is believed that the rejections should be sustained. 

Respectfully submitted, 

/REDENTOR PASIA/ 
Examiner, Art Unit 2474 

Conferees: 
/Aung S. Moe/ 

Supervisory Patent Examiner, Art Unit 2474 
/Ian N. Moore/ 

Supervisory Patent Examiner, Art Unit 2469 



